-
Notifications
You must be signed in to change notification settings - Fork 143
Add session persistence support for NGINX Plus users using the sticky cookie directive
#4305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/session-persistence
Are you sure you want to change the base?
Add session persistence support for NGINX Plus users using the sticky cookie directive
#4305
Conversation
sticky cookie directivesticky cookie directive
| units := []unit{ | ||
| {"ms", 1}, | ||
| {"s", 1000}, | ||
| {"m", 60 * 1000}, | ||
| {"h", 60 * 60 * 1000}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can switch its order if we want larger units first.
622cc92 to
ded1099
Compare
sticky cookie directivesticky cookie directive
|
FYI, the release note in the PR description isn't going to be used at all since this is being merged into the feature branch. For the main PR that we merge at the end, we'll want a descriptive release note to discuss the different ways session persistence is supported. |
|
See my comment on the other PR, I think we have to rethink this a bit to support a backend being referenced multiple times, to prevent unintended behavior or blocking desired behavior. |
sticky cookie directivesticky cookie directive
9863bd1 to
758a284
Compare
1b4dc06 to
fc5c7cb
Compare
edd4d9e to
fcad961
Compare
sticky cookie directivesticky cookie directive
fcad961 to
864ddd8
Compare
| Name: sp.Name, | ||
| Expiry: sp.Expiry, | ||
| Path: sp.Path, | ||
| SessionType: string(sp.SessionType), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow! this PR is just huge work and so impressing!
I'm just wondering how we get the exact cookie from the
< Set-Cookie: coffee-cookie=2b13cc98f0224fca47885f32115ef236; expires=Tue, 18-Nov-25 22:17:55 GMT; max-age=600; path=/coffee
to fill in
sticky cookie coffee-cookie expires=1440m path=/coffee
Is this mechanism somewhere inside NGINX?
The cookie isn't something automatically created it can be set by user during the very first request and then LB will always check any new request for the same cookie?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great question.
When we configure:
upstream coffee_backend {
server backend1;
server backend2;
sticky cookie coffee-cookie expires=1440m path=/coffee;
}
we’re not copying an existing cookie into NGINX – we’re just telling NGINX: use a sticky session cookie named coffee-cookie and set its attributes (expires, path, etc.)
On the first request from a client that doesn’t have this cookie yet, NGINX: Picks a backend using the normal Load balancing algorithm. Generates an cookie token (for example 2b13cc98f0224fca47885f32115ef236) and stores a mapping value → backend and sends a Set-Cookie header like:
Set-Cookie: coffee-cookie=2b13cc98f0224fca47885f32115ef236; ...; path=/coffee
The browser then includes that cookie on subsequent requests: Cookie: coffee-cookie=2b13cc98f0224fca47885f32115ef236 and NGINX Plus uses the cookie value to route the request back to the same upstream server. You never need to copy the cookie value into the config; it’s generated and managed by NGINX itself.
Proposed changes
Write a clear and concise description that helps reviewers understand the purpose and impact of your changes. Use the
following format:
Problem: Users want to be able to specify session persistence for their upstreams.
Solution: Add support for session persistence using
sticky cookiedirectives which is only available for NGINX Plus usersTesting: Manual testing
Errors
Spec validation
NGF Errors
non-plus behaviour
non-experimental and non-plus behaviour
Configuration
HTTPRoutes
Case 1: path and expires specified
Case 2 : no expiry, only path specified
Regular expression with other path matches (no path set)
Multiple matches with common prefix
multiple matches with no common prefix
GRPCRoutes (path is always empty for GRPCRoutes
Hostname matching
Exact Method matching
Traffic Splitting with HTTPRoutes
Upstreams generated
Testing Session Persistence
Testing is done using a script by grabbing the cookie session id from the first request and using it in curl request to ensure each request goes to the same backend
HTTPRoutes (coffee -> sticky, tea -> regular)
GRPCRoutes (backend v1 --> normal, backend v2 --> sticky)
Each have 3 endpoints
Note:
RegularExpressionpath matches, we leave the cookie Path empty. A regex can match anywhere within the URL path (for example, /coffee/[A-Za-z]+/tea), so deriving a concrete cookie path from it would be misleading and could unintentionally restrict which requests send the cookie.Please focus on (optional): If you any specific areas where you would like reviewers to focus their attention or provide
specific feedback, add them here.
Closes #4231
Checklist
Before creating a PR, run through this checklist and mark each as complete.
Release notes
If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.